計算器已經回傳 12.0，模型收到結果後第一行也寫下 12.0，final-answer evaluator 最後卻選了 18。這個結果出現在本次工具實驗的第四道計算題，我們得實際檢視一下工具執行和最後答案的差異為何。

題目是 ((25 - 7) * 6) / 9。沒有工具時，模型最後答對 12；接上計算器後，它也產生了正確的 JSON call，executor 回傳 12.0。模型收到結果，第一行同樣寫下 12.0，接著又從頭解釋一次，直到 192-token 上限剛好停在 25 - 7 = 18。Final-answer evaluator 取到最後一個數字 18，於是把這份回答判錯。

question       ((25 - 7) * 6) / 9
tool call      {"tool":"calculator","arguments":{"expression":"(25 - 7) * 6 / 9"}}
tool result    {"value":12.0}
response start 12.0
response end   25 - 7 = 18
extracted      18

工具呼叫只完成了 pipeline 中間的一步，也就是說，有一部份的工作是跟推理模型的權重無關。模型先把問題轉成結構化請求，executor 核對工具名稱與參數、實際執行，再把結果交還模型組織最後回答。Schema 是否通過、模型選了哪一項工具、executor 回傳什麼，以及 final response 是否答對，是四個可以各自失敗的環節。

題目
→ 模型產生 JSON tool call
→ schema validation 與 restricted executor
→ tool result
→ 模型產生 final response
→ final-answer verifier

這次固定使用 Day 26 晉級的 Qwen-trace distilled model。12 道題在任何新輸出以前凍結，計算器、Python expression 與四份文件的 local search 各 4 題；每題先跑一次 no-tool baseline，再跑 tool-assisted pipeline，答案在生成期間維持隱藏。模型負責的 baseline、tool call 與 final response 都在 CUDA 上生成，deterministic executor 則另外接受測試，四個環節分開計分。

在這個小系統裡，calculator 只接受數字與基本運算；python_expr 另外允許 comb、factorial、gcd、round、sqrt；local_search 只搜尋四份固定文件，回傳 source ID、原文與 lexical overlap。Tool call 必須只有 tool 和 arguments 兩個欄位，第一次失敗後最多修正一次。

三種工具的收益完全不同。

預期工具       no-tool   tool-assisted   valid call   選對工具
calculator     4/4       3/4             4/4          4/4
python_expr    1/4       1/4             2/4          0/4
local_search   0/4       4/4             4/4          4/4
全部           5/12      8/12           10/12         8/12

總分從 5/12 增加到 8/12，四題 local search 包辦了全部增加的分數。這四題問的是 Aurora trial 的 batch size、觸發實驗室警報的溶劑、Orion checkpoint 的凍結日期，以及 local telemetry service 使用的 port。Baseline 在 telemetry port 猜了 8080，搜尋則回傳 note-telemetry 的原文，明確寫著 4317。四題 baseline 全錯，加入來源後四題全對。

計算器呈現相反的情況，模型原本已經答對 4/4，工具也四次都算對，最後回答反而掉成 3/4。Python 題的問題更早發生：12 人選 3 人組成委員會時，模型呼叫 local search；求 462 與 1071 的最大公因數時，它把 462 / 1071 送進 calculator，得到 0.431372...。另外兩題把函式呼叫送給只接受基本運算的 calculator，經過 bounded retry 仍未產生有效 call。

sqrt(2) 那題最後仍答對到小數點後六位，靠的是模型自行生成答案。於是「選對工具」與「final answer 正確」雖然剛好都是 8/12，對應的題目並不相同：calculator-04 選對工具後答錯，python-04 沒有有效工具結果卻答對。只看一個總分，這次交換會完全消失。

兩個數值 executor 都先把 expression 解析成 AST，再逐節點核對允許的運算。import、attribute access、open()、comprehension、過大的次方與額外 schema keys 都會被拒絕；10 個正常與惡意案例得到 10/10 預期結果。這份稽核涵蓋的是目前列出的十種輸入，一般 Python sandbox 的安全性仍不在本次證據範圍內。

第一次正式執行甚至還沒歷經這些失敗，程式在第一題 no-tool baseline 之後，因評分器讀取的欄位名稱和目前介面不一致而停止；當時完成題數是 0，正式 calls 與 summary 尚未寫入。修正欄位並通過回歸測試後，才重新完成全部 12 題。

這次結果算是反映一件事情，當你在使用大型推理模型提問，卻給出不理想的答案時，未必是模型本身不夠聰明、或能力不夠好，而是連接模型的回答系統、驗證器等出了差算，無法做出正確的評估。我們可以在本日的結果中觀察到：source-returning search 能補進 prompt 原本缺少的私有事實，計算器與受限 Python 在這組簡單題目上沒有增加正確數，還多出了 routing、schema 與結果轉述的失敗表面。

以本日鐵人賽的例子來看，當工具回傳 12 以後，系統仍要確保不是輸出最後的 18、那個我們不想看到的錯誤答案，意味著推理模型意外的那幾層架構仍然重要：保存每一步狀態、在失敗後做 bounded retry，再由 verifier 決定答案是否真的可以離開系統、輸出到使用者手上。